The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention teaches methods and apparatus for providing a conspiracy between objects within a distributed object operating environment.
Object oriented programming methodologies have received increasing attention over the past several years in response to the growing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques that emphasize procedural models and "linear" code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are "brittle". That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence changes to the data and or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects and interfaces to be reused in different programs. Thus, programmers can develop libraries of "tried and true" objects and interfaces that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
A more recent advance in the field of object oriented methodologies has been the implementation of distributed object operating environments over computers interconnected via a computer network. As used herein, the term "distributed object" or "object" refers to an encapsulated package of code and data that can be manipulated by operations through an interface. Thus, distributed objects will be seen by those skilled in the art of object oriented programming (OOP) as including the basic properties that define traditional programming objects. However, distributed objects differ from traditional programming objects by the inclusion of two important features. First, distributed objects are multilingual. That is, the interfaces of distributed objects are defined using an interface definition language that can be mapped to a variety of different programming languages. One such interface definition language is Object Management Group's IDL. Second, distributed objects are location-independent, i.e., distributed objects can be located anywhere in a network. This contrasts sharply with traditional programming objects which typically exist in a single address space.
Elaborating further on the distributed object operating environment, distributed objects can be object clients or object servers, depending upon whether they are sending requests to other objects or replying to requests from clients. In a distributed object operating environment, requests and replies are made through an Object Request Broker (ORB) that is aware of the locations and status of the objects. One architecture which is suitable for implementing such an ORB is provided by the Common Object Request Broker Architecture (CORBA) specification. The CORBA specification was developed by the Object Management Group (OMG) to define the distributed computing environment world in terms of objects in a distributed client-server environment, where server objects are capable of providing services to clients requesting the service.
When a client calls a target object, certain procedures must be performed to ensure that the target object can perform the requested service. These procedures include identifying and locating the target object, starting the server process (if necessary) under which the target object resides, activating the target object (if necessary), and, finally, establishing a connection with the target object and passing the call. The ORB together with an Object Adapter (OA) is responsible for working with the client and the target object to perform these services.
One prior art model for providing a service will be discussed now with reference to FIG. 1. In explanation, a service 50 is a computer entity which provides a service to a client such as client 52. Typically in the prior art, the service 50 is resident within a single computer process, often called the "server process" or just the "server." The service 50 includes objects (standard objects or distributed objects) such as object.sub.-- 1 54, object.sub.-- 2 56, and object.sub.-- 3 56. These objects work together to provide the service 50. Each of object.sub.-- 1 54, object.sub.-- 2 56, and object.sub.-- 3 58 will, respectively, have an interface such as interface.sub.-- 1 60, an interface.sub.-- 2 62, and an interface.sub.-- 3 64. As discussed previously, access to the data and procedures of the object are allowed only through the object interface and are therefore limited by the nature of the interface. This insures modularity of the objects.
While the prior art model of FIG. 1 allows multiple objects to work together in providing the service 50 to the client 52, there are limitations inherent to this model due to the modular nature of objects and the constraints presented by the interfaces. For example, in many scenarios the object interfaces will be written to hide and protect the internal object data and procedures from the client 52. However, for the server 50 to operate best (if at all), it may be necessary for the objects to conspire with each other. For example, the objects may require communication with each other which lies outside the capabilities of their respective interfaces. Perhaps object.sub.-- 1 54 needs to know a value of state contained in object.sub.-- 3 58, but it is desirable to protect and/or hide this value from the client 52. Thus the interface.sub.-- 3 wouldn't provide for object.sub.-- 1 54 to access this value and the service 50 would be unable to fulfill its function. What is needed are methods and apparatus for providing a conspiracy between objects. The conspiracy will enable interaction between objects which occurs "behind" the interface. For example, the conspiracy will allow the conspirator objects to share persistent state.